SYSTEM AND METHOD FOR UTILIZING FROFORMA PROCESSING OF 



ADTUSTMENTS IN CONSOLIDATION PROCESSES 



5 BACKGROUND OF THE INVENTION 

Field of the Invention 

[0001] The present invention relates to accounting and more particularly to 
processing of adjustments in consolidations. 

10 Description of Related Art 

[0002] Consolidation is the combination of accounts of multiple source ledgers 
into one consolidated ledger. These multiple source ledgers may contain accounts of a 
parent company and all subsidiaries within a single business entity. Referring to FIG. la, a 
conventional consolidation system is shown. Typically, data entries from the multiple 

1 5 source ledgers are sent to the consolidation ledger 102. Then, the consolidation processor 
104 performs consolidation processing on the consolidation ledger 102 entries. The 
consolidation processor 104 usually comprises an inter-company eliminations module 106 
for performing inter-company eliminations (i.e., elimination of activities between two 
subsidiaries of the same business entity), a NCI eliminations module 108 for performing 

2 0 non-controlling interest eliminations (i.e., elimination of equity of subsidiary against a 
parent investment), and an equitization module 110 for reflecting net income of a 
subsidiary on a parent's ledger. Once the consolidation processing is complete, results are 
output to a journal 112, and posted by a post module 114 back to the consolidation ledger 
102. 

2 5 [0003] However, users often need to make adjustments to the consolidation data 

(e.g., for statutory or management purposes). Referring now to FIG. lb, a prior art 
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consolidation system for performing adjustments to a consolidation ledger 102 is shown. 
The consolidation process as described in connection with FIG. la (i.e., solid lines) is 
initially performed. In the adjustment consolidation process (i.e., dashed lines), 
adjustment entries are provided to an adjustment journal 118. The adjustment journal 118 
5 is then posted to the consolidation ledger 102 via the post module 114. Once posted, the 
consolidation data (i.e., original ledger rows along with the adjustment rows) are then 
processed through the consolidation processor 104, and the results are output to the 
journal 112. Finally, the journal 112 entries are posted by the post module 114 back to the 
consolidation ledger. The contents of the consolidation ledger 102 may be viewed via an 
1 0 inquiry module 116. 

[0004] Disadvantageously, this prior art system requires the posting of 
adjustments to the consolidation ledger 102, reprocessing of all relevant data in the 
consolidation ledger 102, and posting of results back to the consolidation ledger 102. 
Consequently, the prior art consolidation system is inefficient and time consuming. For 

1 5 example, a parent company and its subsidiaries may have 2,000,000 rows of data in the 

consolidation ledger 102. Of these 2,000,000 rows of data, a consolidation process may run 
with 500,000 ledger rows (e.g., revenues and expenses for the subsidiaries) which total 
$75,000 across 199 different departments. Consolidation processing will result in a 200 line 
(i.e., row) journal 112 entry (one line for each of the 199 different departments and one line 

2 0 debiting a parent investment for $75,000) for a total of $75,000. Subsequently, the journal 
112 entry is posted to the consolidation ledger 102 resulting in a new overall row count of 
2,000,200. 

[ 0005] Assume now that the adjustment journal 118 contains additional revenue 
for five departments for a total of $3,000. Using double entry accounting, there are ten 
2 5 rows of detail in the adjustment journal 118 (i.e., five rows for revenue entries and five 
rows with offsets to cash). Initially, the adjustment journal 118 is posted by the post 
module 114 to the consolidation ledger 102 resulting in the row count rising to 2,000,210. 
The consolidation processor 104 then runs the consolidation process. First, the results of 
the previous consolidation processing are reversed from a ledger balance (i.e., 200 rows are 
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updated, 0 rows are added or deleted). Then, 500,010 ledger rows (i.e., the updated 
500,000 ledger rows and the 10 rows of details with the adjustments) are input to the 
consolidation processor 104 which now total $78,000 across 204 different departments (199 
original departments and five departments with the adjustments). The result is an output 
5 with a 205 line (i.e., row) journal 112 entry (i.e., one line for each of the 204 different 

departments and one line debiting a parent investment for $78,000). Finally, the 205 line 
journal 112 entry is posted to the consolidation ledger 102 updating the 200 rows added in 
the previously consolidation processing and adding five new rows. Resultingly, the 
consolidation ledger 102 now contains 2,000,215 ledger rows. 

10 [0006] As is evident from this example, the amount of time required to process 

just five adjustments is approximately the same as for processing an entire data set (i.e., the 
original 500,000 ledger rows). Thus, prior art systems are inefficient. Furthermore, 
because the post-adjustment consolidation journal 112 is posted to the consolidation ledger 
102 before a user is allowed to view the results, there is limited visibility into how 

1 5 adjustments impact an overall consolidation prior to approval and finalization. 

Consequently, prior art consolidation systems do not allow the user to quickly and 
efficiently perform "what-if" analyses and incremental changes to consolidated data. 

[0007] Therefore, there is a need for a system and method for efficiently 
processing adjustments in consolidation. 
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SUMMARY OF THE INVENTION 



[0008] The present invention provides a system and method for utilizing 
proforma processing on adjustments in consolidation processes. The system comprises a 
proforma consolidation processor configured for consolidating at least one adjustment 
5 entry received from an adjustment journal. The proforma consolidation processor only 
performs consolidation on the at least one adjustment entry. The results of the proforma 
consolidation (i.e., consolidated adjustment entries) are then output to a pending journal. 
An inquiry module allows display of pending journal entries along with current 
consolidation ledger balances. If the results of the proforma consolidation are acceptable, 
1 0 then a post module posts the pending journal and the at least one adjustment to the 
consolidation ledger. 

[0009] According to an exemplary method, adjustments are processed separately 
from the previously consolidated data stored in the consolidation ledger. At least one 
adjustment entry from an adjustment journal is sent to a proforma consolidation processor. 
1 5 The at least one adjustment is processed and is output to a pending journal. Subsequently, 
a user may view pending journal entries along with current consolidation ledger balances. 
If the results are acceptable, then the pending journal and the at least one adjustment are 
posted to the consolidation ledger . 

[ 0010 ] Thus, the present invention allows the user to have visibility into how 
2 0 adjustments impact overall consolidation without having to post the adjustments and 

results to the consolidation ledger. This allows for "what-if" analysis to be performed (i.e., 
inputting various adjustments to test the outcome). Additionally, because the proforma 
consolidation processor only processes the adjustments, the overall consolidation process 
is efficient and quick. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



[0011] FIG. la is a block diagram of a prior art consolidation system; 

[ 0012 ] FIG. lb is a block diagram of the prior art consolidation system providing 
for adjustment processing; 
5 [0013] FIG. 2a is an exemplary block diagram of a prof orma consolidation 

system, according to one embodiment of the present invention; 

[0014] FIG. 2b is an exemplary block diagram of the prof orma consolidation 
processor of FIG. 2a; 

[0015] FIG. 3 is a flowchart of an exemplary method for performing prof orma 
1 0 consolidation; 

[0016] FIG. 4 is an exemplary screen shot of a consolidation manager page; 

[0017 ] FIG. 5 is an exemplary screen shot of a balance page; 

[0018] FIG. 6 is an exemplary screen shot of adjustment journal entries; 

[0019] FIG. 7 is an exemplary pro forma equitization page; 
1 5 [0020] FIG. 8 is an exemplary proforma eliminations page; 

[0021] FIG. 9 is an exemplary journal selection page; 

[ 0022 ] FIG. 10a is a proforma trial balance page, according to one embodiment of 
the present invention; and 

[0023] FIG. 1 0b is an alternative proforma trial balance page, according to 
2 0 another embodiment of the present invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 



[ 0024 ] The present invention provides a system and method for utilizing 
proforma processing of adjustments in consolidation processes. Unlike prior art systems, 
the present invention processes adjustments separately from data stored in a consolidation 
5 ledger before the adjustments are posted to the consolidation ledger. Further, a user may 
decide, upon viewing results of proforma processing, whether to post the adjustments and 
corresponding results to the consolidation ledger. This allows for visibility into how 
adjustments impact overall consolidation and for "what-if" analyses to be performed. 
[0025] Referring to FIG. 2a, a block diagram of an exemplary proforma 

1 0 consolidation system according to one embodiment of the present invention is shown. In 
this embodiment, the consolidation processing (i.e., solid lines) is the same as the prior art 
system. Source information from various source ledgers are input to a consolidation 
ledger 202. A consolidation processor 204 comprising an inter-company eliminations 
module 206, a NCI (non-controlling interest) module 208, and an equitization module 210, 

1 5 performs consolidation on the relevant consolidation ledger 202 entries. Once the 

consolidation processing is complete, results are output to a journal 212, and posted by a 
post module 214 back to the consolidation ledger 202. The contents of the consolidation 
ledger 202 may be viewed via an inquiry module 216. 

[0026] The present invention provides an efficient system for consolidation of 

2 0 adjustments (i.e., dashed lines). In an exemplary embodiment, adjustment entries (e.g., 
rows and/ or lines) are provided to an adjustment journal 218. These adjustment entries, 
unlike the prior art, are not posted to the consolidation ledger 202 for processing by the 
consolidation processor 204. Instead, the adjustment entries are forwarded to a proforma 
consolidation processor 220. According to the present invention, the proforma 

2 5 consolidation processor 220 performs consolidation on only the adjustment entries. The 
results from the proforma consolidation processor 220 are output to a pending journal 222 
resulting in at least one pending journal entry (i.e., consolidate adjustment entry). 

[ 0027 ] A user may then view the pending journal entries of the pending journal 
222 via the inquiry module 216. The inquiry module 216 may display the pending journal 
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entries, the corresponding adjustment entries from the adjustment journal 218, at least one 
ledger balance from the consolidation ledger 202, at least one proforma ledger balance, or 
any combination of these, as will described further herein. The proforma ledger balances 
are resulting balances should the user decide to post pending journal entries to the 
5 consolidation ledger 202. Thus, the user has visibility into how the adjustment entries 
impact an overall consolidation prior to approving and finalizing the posting of 
adjustment entries to the consolidation ledger 202. Should the user decide to post the 
adjustment entries, the post module 214 will post both the adjustment entries from the 
adjustment journal 218 and the pending journal entries from the pending journal 222 to the 

1 0 consolidation ledger 202 thus updating the data in the consolidation ledger 202. 

[0028] The user may perform 'what if scenarios by modifying adjustments 
entries in the adjustment journal 218. For example, the user may run proforma 
consolidation processing with a first set of adjustment entries and view the results of an 
impact this first set will cause on the ledger balance in the consolidation ledger 202. The 

1 5 user may then input a second set of adjustment entries, different from the first set, run the 
proforma consolidation processing on the second set, and view the results of an impact this 
second set will cause on the ledger balance. This 'what if iterative process may be 
repeated as many times as desired by the user. Thus, the user is able to see how changes to 
the adjustment entries may affect the outcome of the overall consolidation process in a fast 

20 and efficient manner. 

[0029] The present invention is able to process adjustment entries at a faster rate 
then prior art systems. Returning to the example previously discussed, a parent company 
and its subsidiaries have 2,000,000 rows of data in the consolidation ledger 202. Of these 
2,000,000 rows of data, a consolidation process may run with 500,000 ledger rows (e.g., 

2 5 revenues and expenses for the subsidiaries) which total $75,000 across 199 different 

departments. Consolidation processing will result in a 200 line journal 212 entry (one line 
for each of the 199 different departments and one line debiting a parent investment for 
$75,000) for a total of $75,000. Subsequently, the journal 212 entry is posted to the 
consolidation ledger 102 resulting in a new overall row count of 2,000,200. 
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[ 0030 ] However, assume now that the adjustment journal 218 contains 
additional revenue for five departments for a total of $3,000. Using double entry 
accounting, there are ten rows of detail in the adjustment journal 218 (i.e., five rows for 
revenue entries and five rows with offsets to cash). In the present invention, the 
5 adjustment entries are not immediately posted to the consolidation ledger 202. Instead, the 
five rows of revenue entries are sent to the proforma processor 220. In this embodiment, 
the results of the previous consolidation processing are not affected. Further, the proforma 
consolidation processor 220 only processes the five revenue adjustment entry rows (i.e., the 
five revenue /expense accounts). 

10 [0031] A result from the proforma consolidation processor 220 is a six line 

pending journal 222 entry (one line for each of the five different departments for a total of 
$3,000 and one line debiting the parent investment account for $3,000). The pending 
journal 222 is not immediately posted to the consolidation ledger 202, but can be reviewed 
via the inquiry module 216. If upon review, the results are approved, the ten line 

1 5 adjustment journal 218 is posted by the post module 214 to the consolidation ledger 202, 
thus adding 10 rows to the consolidation ledger and raising the overall row count to 
2,000,210. The proforma pending journal 222 is also posted to the consolidation ledger 202 
- updating one row and adding five new rows to the consolidation ledger 202 resulting in 
the overall row count of 2,000,215. Thus, an end result of the proforma consolidation 

2 0 system is a same number of rows and ledger balance as the prior art system. However, the 
process of the present invention is much more efficient - proforma consolidating only five 
rows of data in contrast to the 2,000,210 rows of data in the prior art system. 

[0032 ] Referring now to FIG. 2b, a more detailed view of the exemplary 
proforma consolidation processor 220 is shown. The proforma consolidation processor 220 

2 5 comprises a proforma inter-company eliminations module 224, a proforma non- 

controlling-interest (NCI) eliminations module 226, and a proforma equitization module 
228. The proforma consolidation processor 220 is essentially identical to the consolidation 
processor 204 (FIG. 2a) but configured for only processing adjustment entries. Both the 
proforma consolidation processor 220 and the consolidation processor 204 utilize the same 

3 0 set of user defined rules which dictate which accounts to read as inputs, which accounts to 
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write to as output, what relationships are between business units, etc. Furthermore, both 
consolidation processors 220 and 204 create journals which may (in the case of the 
proforma consolidation processor 220) or will (in the case of the consolidation processor 
204) be posted to the consolidation ledger 202 (FIG. 2b) for the purpose of producing a set 
5 of consolidated financial statements. A key difference between the two consolidation 
processors 220 and 204, however, is that the proforma consolidation processor 220 reads 
input data (e.g., account codes and amounts to process) from a not-yet-posted journal (i.e., 
adjustment journal 218 of FIG. 2a) while the regular consolidation processor 204 reads 
input data from ledger balances in the consolidation ledger 202. A matching of account 

1 0 codes of the pending journal 222 and the ledger balances in the consolidation ledger 202 
allows the posting of the pending journal 222 entries into the consolidation ledger 202. The 
matching of account codes also allows for the display of the proforma ledger balance as 
will be discussed further herein. 

[0033] FIG. 3 is a flowchart of an exemplary method for performing proforma 

1 5 consolidation of adjustments according to an embodiment of the present invention. In step 
302, at least one adjustment entry is received by the proforma consolidation processor 220 
(FIG. 2a) from the adjustment journal 218 (FIG. 2a). The at least one adjustment entry is 
processed by the proforma consolidation processor 220 and one or more consolidated 
adjustment entries are generated in step 304. The at least one adjustment entry may be 

2 0 processed via the proforma inter-company eliminations module 224 (FIG. 2b), the 

proforma NCI eliminations module 226 (FIG. 2b), the proforma equitization module 228 
(FIG. 2b), or any combination of these or other modules. 

[0034] The output (i.e., consolidated adjustment entries) of the proforma 
consolidation processor 220 are temporarily stored in the pending journal 222 (FIG. 2a) in 

2 5 step 306. In optional step 308, the user may review the consolidated adjustment entries 

(i.e., pending journal entries or rows). In one embodiment, the pending journal entries 
along with current ledger balances or rows from the consolidation ledger 202 (FIG. 2a) are 
forwarded to the inquiry module 216 which displays the entries, balances, and an overall 
proforma ledger balance (i.e., a result of a combination of the pending journal entries and 

3 0 the current ledger balances should the at least one adjustment entry be posted). 
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[0035] Based on the review, the user may choose to post the at least one 
adjustment entry and the one or more consolidated adjustment entries in optional step 310. 
If the at least one adjustment entry is posted, then in step 312, the consolidation ledger 202 
is updated, and further adjustments may be consolidated in step 314. However, if the user 
5 decides not to post the adjustment entries, then the user may consider consolidating other 
adjustments in step 314 (e.g., incremental changes to the adjustment entries to obtain a 
different result). If further adjustments are input into the system, then the method returns 
to step 302. 

[0036] Referring now to FIG. 4, an exemplary screen shot of a consolidation 
1 0 manager page 400 is shown. In this example, a business unit 402 being consolidated is the 
"United States Consolidation." The consolidation type taking place is "actual 
consolidation" according to a scenario ID 404. Alternatively, other consolidation types 
may comprise different currency consolidations or budget consolidations. Further, this 
consolidation is occurring in a fiscal year 406 of "2002" over a period 408 of October (i.e., 
15 "10"). 

[ 0037 ] All rules pertaining to how this consolidation scenario is built is stored in 
a model ID 410. In the present example, the model ID 410 is based on rules stored in a 
"simple consolidation model." Each model defines various characteristics of the 
consolidation such as currency, grouping of entities or units within the consolidation 
2 0 business unit 402, grouping of entities or units by management organization, etc. These 
rules instruct the system as to how ledger and adjustment data rows (i.e., entries) may be 
consolidated. 

[ 0038 ] In the present example, a lower left corner of the exemplary screen shot 
shows a consolidation source menu 412 (i.e., a source tree). This consolidation source 

2 5 menu 412 shows individual sources of data provided for the present consolidation. The 
same node sources are shown in a consolidation graph 416 shown on a lower right corner 
of the exemplary screen shot. As shown, within the United States Consolidation, three 
consolidation nodes 418 provide the source data. In this example, the three consolidation 
nodes 418 are "National Electric Company," (e.g., a parent company) "US Legal Entity 1," 

30 and "US Legal Entity 2." Referring to the consolidation source menu 412, source data (e.g., 
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subsidiaries) for US Legal Entity 1 comprises a freight subsidiary ("FRET") and a shipping 
subsidiary ("SHIP"). Similarly, source data for US Legal Entity 2 comprises a mining 
subsidiary ("MINE") and an oil subsidiary ("OIL"). These subsidiaries may also be 
considered business units within their respective consolidation nodes 418. 
5 [0039] As shown in the exemplary consolidation source menu or tree 412, each 

branch of the source menu 412 contains an entity that stores elimination balances for that 
particular branch. Thus, for example, "ELIMU" 426 stores total eliminations balances for 
the business unit 402 United States Consolidation. Within the United States Consolidation, 
a "ELMN1" 428 and a "ELMN2" 430 stores elimination balances for their respective branch 

10 of the source menu 412. Thus, ELMN1 428 stores the total eliminations balances for the US 
Legal Entity 1 while ELMN2 430 stores the total eliminations balances for the US Legal 
Entity 2. In the present example, the business unit, "USCON," is selected in the source 
menu 412 (as shown highlighted in the source menu 412) for a more detailed display in the 
consolidation graph 416. In a further embodiment, the user may select any of the 

1 5 consolidation source nodes or any branches on the source menu 412 (e.g., USLE1, USLE2, 
ELMN1, ELMN2, FRET, SHIP, etc.) for a more detailed display in the consolidation graph 
416. 

[0040] The type of consolidation performed on entries from the data sources is 
shown by various columns in the consolidation graph 416. As shown, an equitization 

2 0 column 420 indicates that the data sources are equitized for all three consolidation nodes 
418. Similarly, all three consolidation nodes 418 have had inter-company eliminations, as 
shown in an elimination column 422, and non-controlling interest eliminations, as shown 
in an non-controlling column 424, performed. Because all consolidation is marked 
completed in this consolidation graph 416 (i.e., check marked in columns 420, 422, and 

2 5 424), the original consolidation process through the consolidation processor 204 (FIG. 2a) is 
completed. 

[0041] FIG. 5 is an exemplary screen shot of ledger balances stored in the 
consolidation ledger 202 (FIG. 2a) based on the original consolidation process through the 
consolidation processor 204 (FIG. 2a) for the consolidation process as described on the 
30 manager page 400 of FIG. 4. According to the present invention, this exemplary screen 

{00098546vl}ll PA2268 



shot will be displayed via the inquiry module 216 (FIG. 2a). In the present example, the 
consolidation node "National Electric Company" 512 is selected for further review. A total 
balance 502 for this node is $46,173.40 (for the selected accounts), and an account balance 
chart 504 displays a breakdown of the total balance 502. An account column 506 displays 
5 an account code for each ledger entry in this node, while a description column 508 displays 
a definition for each account code. Finally, a ledger balance column 510 displays a ledger 
balance for each account code of the node, the total of which will equal the total balance 
502. For example, account code 170024 is an investment in the shipping subsidiary during 
the current year with the ledger balance of $549.00. It should be noted that FIG. 5 
1 0 illustrates a subset of the accounts to be displayed. An alternative embodiment may 
display all accounts. 

[ 0042 ] Referring now to FIG. 6, an exemplary screen shot of adjustment journal 
entries (e.g., stored in the adjustment journal 218 of FIG. 2a) is shown. According to the 
present example, the adjustment journal entries are identified as "ADJ103102B" in a 

1 5 journal ID 602 and created on a journal date 604 of October 31, 2002. Because status 606 is 
"valid," the adjustment entries have not been posted to the consolidation ledger 202 (FIG. 
2a). Information regarding the journal is provided in a journal information section 608 of 
the screen shot. Accordingly, the journal pertains to a fiscal year 610 of "2002" for a period 
612 of "10" (i.e., October) and will be recorded in a base currency 614 of U.S. dollars. A 

2 0 description 615 allows a user to define the adjustments - in this case, "adjustment to record 
additional October sales from SHIP subsidiary." 

[ 0043 ] A journal lines chart 616 displays actual adjustment entries to the 
adjustment journal 218 and comprises a ledger unit 618, an account code 620, a department 
622, a product ID 624, a currency 626 for the adjustment line, and an amount 628. In the 

2 5 present example, a first line shows a sale of $500.00 USD (in SHIP'S sales account #400000), 
while a second line shows an account receivable of $500.00 USD from the sale (in SHIP'S 
accounts receivable account #120000) for the shipping subsidiary. Thus in a journal totals 
chart 630, a total debit 632 for $500.00 and a total credit 634 of $500.00 are shown for the 
shipping subsidiary. 
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[0044] Referring now to FIG. 7, an exemplary screen shot of a equitization 
consolidation page 700 is shown. This equitization consolidation page 700 provides 
instructions to the system as to how to perform equitization consolidation on adjustments. 
Continuing with the same example of FIGs. 4-6, equitization consolidation will be 
5 performed on the United States Consolidation (unit 702) for the 2002 fiscal year 704 for the 
October period 706 (i.e., period "10") within the actual consolidation scenario ID 708 (i.e., 
actual consolidation 1 as indicated by "CONACT1"). Because a proforma field 710 is 
checked, the equitization consolidation will be a proforma equitization consolidation via 
the proforma consolidation processor 220 (FIG. 2a). A user may choose adjustment 

1 0 journal(s) to perform proforma equitization consolidation upon by selecting a select 

journals hyperlink 712. Should the user decide to not run a proforma consolidation, the 
user may instead select a post journal created field 714 which will post the balances of a 
consolidation (i.e., non-prof orma consolidation) to the consolidation ledger 202 (FIG. 2a). 

[ 0045 ] FIG. 8 illustrates an exemplary screen shot of a eliminations consolidation 

1 5 page 800. This page 800 shows elimination consolidation instructions for the United States 
Consolidation unit 802 with a scenario ID 804 (i.e., actual consolidation 1 as indicated by 
"CONACT1") over a period 806 (i.e., "10" or October) same as that of FIGs. 4-7. In the 
present example, a process inter-company eliminations field 808 is checked for 
consolidation, and the consolidation will be proforma consolidation as indicated by a 

2 0 checked proforma field 810. Similar to the equitization consolidation page 700, the user 
may chose adjustment journal(s) to perform proforma eliminations consolidation upon by 
selecting a select journals hyperlink 812. The user may also select, in addition to or instead 
of the process inter-company eliminations field 808, a process non-controlling interest 
eliminations field 814 in order to instruct the system to conduct proforma NCI eliminations 

2 5 consolidation. Should the user decide to not run a proforma consolidation, the user may 

instead select a post journal created field 814 which will post the balances of a 
consolidation (i.e., non-proforma consolidation) to the consolidation ledger 202 (FIG. 2a). 

[0046] Referring now to FIG. 9, an exemplary journal selection screen shot page 
900 is shown. This journal selection page 900 is displayed when the user selects the select 

3 0 journals hyperlink 712 (FIG. 7) or 812 (FIG. 8). The screen shot page 900 shows a listing of 
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adjustment journals identified in a journal ID 902 column along with a date of creation of 
the adjustment journal in a journal data 904 column. In the present invention, these 
adjustment journals are stored in the adjustment journal 218 (FIG. 2a). As shown, the user 
may indicate in a select column 906 which adjustment journals should be consolidated 
5 through the proforma consolidation processor 220 of FIG 2a). 

[0047] FIG. 10a is an exemplary screen shot of a proforma trial balance page 1000 
according to one embodiment. This proforma trial balance page 1000 is displayed via the 
inquiry module 216 after the system has performed a proforma consolidation. At a request 
of the user, the inquiry module 216 will obtain pending journal balance (i.e., pending 

1 0 journal entries) 1002 resulting from the proforma consolidation stored in the pending 
journal 222 (FIG. 2a) and current ledger balance 1004 from the consolidation ledger 202 
(FIG. 2a) for display. The proforma trial balance page 1000 will also display a proforma 
ledger balance 1006 which is a resultant ledger balance should the adjustment(s) and 
pending journal entries 1002 be posted to the consolidation ledger 202. 

15 [0048] Referring back to the ongoing example of FIGs. 4-9, account code 1 70024 

(shown in an account 1008 column) has a trial balance (i.e., ledger balance 510 in the 
consolidation ledger 202 post-consolidation through the consolidation processor 204) of 
$549.00 as shown in FIG. 5. This ledger balance 510 is provided to the inquiry module 216 
and displayed as the ledger balance 1004. Pending journal balance (i.e., pending journal 

2 0 entry) 1002 from the proforma consolidation processing of the adjustment journal entries 
of FIG. 6 of $500.00 for account 170024 and -$500.00 for account 400011 are obtained from 
the pending journal 222 and displayed. The proforma ledger balance 1006 is then a 
combination of the ledger balance 1004 (i.e., for account code 170024 is $549.00) and the 
pending journal balance 1002 (i.e., for account code 170024 is $500.00). In the present 

2 5 example, the proforma ledger balance 1006 is $1,049.00. for account code 170024. 

[0049] In the present proforma trial balance page 1000, only accounts 1008 
having pending journal balances 1002 are displayed. However, in an alternative 
embodiment, all accounts 1008 in the consolidation ledger 202 may be displayed. In yet a 
further embodiment, the user is able to select the accounts 1008 to view via the inquiry 

30 module 216 (see for example FIG. 10b which shows the same accounts as in the FIG. 5 
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balance page). Based on a review of the proforma trial balance page 1000, the user may 
decide to post the adjustment entries and pending journal balances 1006 to the 
consolidation ledger 202. Alternatively, the user may perform more proforma 
consolidation processing using different adjustment entries. 
5 [ 0050 ] The exemplary screen shots of FIGs. 4-10b are illustrative according to 

embodiments of the present invention. It should be noted that the layouts and fields of the 
screen shots may be organized in a different fashion and other or different fields may be 
utilized. 

[0051] The present invention has been described above with reference to 
1 0 exemplary embodiments. It will be apparent to those skilled in the art that various 

modifications may be made and other embodiments can be used without departing from 
the broader scope of the present invention. Therefore, these and other variations upon the 
exemplary embodiments are intended to be covered by the present invention. 
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